REST API (Representational State Transfer Application Programming Interface) is a widely used approach for enabling applications, services, and systems to communicate with each other over a network using standard HTTP methods. REST APIs are commonly used in web applications, mobile applications, automation frameworks, microservices, cloud applications, and integration testing.
In software testing and Selenium automation, understanding REST APIs is important because modern applications often depend on backend APIs for authentication, user management, product information, search, orders, payments, and other business operations. API testing allows testers to validate backend functionality directly without depending entirely on the user interface.
REST APIs generally use HTTP methods such as GET, POST, PUT, PATCH, and DELETE to perform operations on resources. Data is commonly exchanged using formats such as JSON.
Course Resource: Selenium Training | Register for Course Demo
An API (Application Programming Interface) is a set of rules and mechanisms that allows one software application to communicate with another application or service.
For example, when a mobile application displays customer information, the application may send a request to a backend API. The API processes the request, communicates with the database or another service, and returns the required response.
Client Application
|
| HTTP Request
v
REST API
|
v
Application
Server
|
v
Database
|
v
HTTP Response
|
v
Client Application
REST stands for Representational State Transfer. It is an architectural style for designing network-based services.
REST uses standard web technologies, particularly HTTP, to allow clients and servers to communicate using resources and operations.
REST is not a programming language or a specific software tool. It is a set of architectural principles used to design APIs.
A REST API is an API designed according to REST architectural principles. It exposes resources through URLs and uses HTTP methods to perform operations on those resources.
For example, an API may expose a user resource through:
GET https://example.com/api/usersThe server can return a JSON response containing user information.
REST API testing allows testers to validate backend functionality directly. API testing can be performed before, alongside, or independently of UI testing.
A typical REST API architecture contains a client, API/server layer, business logic, database, and external services.
Client
|
| HTTP Request
v
REST API Endpoint
|
v
Controller / Route
|
v
Business Logic
|
v
Database / External Service
|
v
Response
|
v
Client
The client is the application that sends requests to the server. The server receives requests, processes them, and returns responses.
| Component | Responsibility |
|---|---|
| Client | Sends requests and consumes responses |
| Server | Processes requests and generates responses |
| API | Defines the communication interface |
| Database | Stores application data |
In REST, information is represented as resources. A resource can represent a user, product, order, employee, customer, payment, or another business entity.
For example:
/users
/products
/orders
/customers
/payments
Each resource can have a unique URL or endpoint.
An endpoint is a specific URL through which a client can interact with an API resource.
Example:
https://example.com/api/usersSpecific user:
https://example.com/api/users/101Here, /users represents the resource and /101 identifies a particular user.
REST APIs commonly use the HTTP (HyperText Transfer Protocol) protocol for communication between clients and servers.
HTTP defines methods, headers, status codes, and other mechanisms used to communicate between systems.
| HTTP Concept | Purpose |
|---|---|
| Method | Defines the requested operation |
| URL | Identifies the resource |
| Headers | Provide additional request or response information |
| Body | Contains request or response data |
| Status Code | Indicates the result of the request |
The most commonly used HTTP methods in REST APIs are:
| Method | Common Purpose |
|---|---|
| GET | Retrieve data |
| POST | Create a resource or submit data |
| PUT | Replace or update a resource |
| PATCH | Partially update a resource |
| DELETE | Delete a resource |
The GET method is commonly used to retrieve information from a server.
GET /api/usersExample:
GET https://example.com/api/usersA successful response may contain a list of users.
A GET request can retrieve a specific resource by including an identifier in the URL.
GET /api/users/101This request asks the server for the user whose identifier is 101.
The POST method is commonly used to submit data to the server and create a new resource.
POST /api/usersExample JSON request body:
{
"name": "John",
"email": "[email protected]",
"role": "tester"
}
The PUT method is commonly used to replace or update an existing resource.
PUT /api/users/101Example:
{
"name": "John Updated",
"email": "[email protected]",
"role": "tester"
}
The PATCH method is commonly used when only part of an existing resource needs to be updated.
PATCH /api/users/101Example:
{
"role": "admin"
}
Unlike a full replacement, PATCH is generally used for partial modifications.
The DELETE method is used to request deletion of a resource.
DELETE /api/users/101The server may return a success status indicating that the resource was deleted or that the deletion request was accepted.
REST APIs are commonly associated with CRUD operations.
| CRUD | HTTP Method | Example |
|---|---|---|
| Create | POST | POST /users |
| Read | GET | GET /users/101 |
| Update | PUT/PATCH | PUT /users/101 |
| Delete | DELETE | DELETE /users/101 |
An API request is the message sent by a client to a server.
A request can contain:
POST /api/users
Content-Type: application/json
Authorization: Bearer <token>
{
"name": "John",
"email": "[email protected]"
}
An API response is the message returned by the server after processing a request.
A response can contain:
HTTP status codes indicate the result of an HTTP request.
| Status Code | Meaning | Common Usage |
|---|---|---|
| 200 | OK | Successful request |
| 201 | Created | Resource successfully created |
| 202 | Accepted | Request accepted for processing |
| 204 | No Content | Successful response without response body |
| 400 | Bad Request | Invalid request |
| 401 | Unauthorized | Authentication required or invalid |
| 403 | Forbidden | Request understood but not permitted |
| 404 | Not Found | Resource or endpoint not found |
| 405 | Method Not Allowed | HTTP method not supported for the resource |
| 409 | Conflict | Request conflicts with current resource state |
| 500 | Internal Server Error | Unexpected server-side error |
| 502 | Bad Gateway | Gateway received an invalid upstream response |
| 503 | Service Unavailable | Service temporarily unavailable |
JSON (JavaScript Object Notation) is one of the most commonly used formats for exchanging structured data through REST APIs.
Example:
{
"id": 101,
"name": "John",
"email": "[email protected]",
"active": true
}
JSON represents information using objects, arrays, strings, numbers, booleans, and null values.
A JSON object contains key-value pairs.
{
"name": "John",
"age": 30,
"active": true
}
Here:
A JSON array contains multiple values or objects.
{
"users": [
{
"id": 1,
"name": "John"
},
{
"id": 2,
"name": "David"
}
]
}
HTTP headers provide additional information about a request.
Common request headers include:
| Header | Purpose |
|---|---|
| Content-Type | Specifies the format of the request body |
| Accept | Indicates acceptable response formats |
| Authorization | Provides authentication credentials or token |
| User-Agent | Identifies the client software |
The Content-Type header tells the server what format is being sent in the request body.
For JSON:
Content-Type: application/jsonExample:
POST /api/users
Content-Type: application/json
{
"name": "John"
}
The Accept header indicates the response formats that the client can process.
Accept: application/jsonThis is commonly used when the client expects a JSON response.
Many APIs require authentication to ensure that only authorized clients can access protected resources.
Common authentication mechanisms include:
A bearer token is commonly sent through the Authorization header.
Authorization: Bearer <access-token>Example request:
GET /api/profile
Authorization: Bearer abc123token
Real access tokens should be handled securely and should not be exposed in source code or test reports.
Some APIs require an API key to identify or authorize the client.
An API key may be supplied through a header such as:
X-API-Key: <api-key>The exact header name and authentication process depend on the API design.
A path parameter identifies a specific resource within the URL.
GET /api/users/101Here, 101 is the user identifier.
Another example:
GET /api/products/5001Query parameters are commonly used to filter, search, sort, or paginate resources.
GET /api/products?category=electronicsMultiple query parameters can be supplied:
GET /api/products?category=electronics&sort=price&page=2| Feature | Path Parameter | Query Parameter |
|---|---|---|
| Purpose | Identify a resource | Filter or modify a request |
| Example | /users/101 | /users?role=admin |
| Common Usage | Specific resource | Search/filter/sort/pagination |
The request body contains data sent to the server, particularly for methods such as POST, PUT, and PATCH.
{
"name": "John",
"email": "[email protected]",
"role": "tester"
}
The response body contains data returned by the server.
{
"id": 101,
"name": "John",
"email": "[email protected]",
"role": "tester"
}
One important REST principle is statelessness. Each request should contain the information necessary for the server to process that request.
The server should not depend on hidden client-session state to understand the meaning of an individual request.
Request 1
Client ----------------> Server
Request 2
Client ----------------> Server
Request 3
Client ----------------> Server
Each request contains the information
needed to process that request.
A typical REST API URL may contain a base URL, API version, resource, identifier, and query parameters.
https://example.com/api/v1/users/101?active=true| Part | Example |
|---|---|
| Protocol | https |
| Host | example.com |
| Base Path | /api |
| Version | /v1 |
| Resource | /users |
| Identifier | /101 |
| Query Parameter | ?active=true |
API versioning allows an API provider to introduce changes while maintaining compatibility with existing clients.
A common URL-based approach is:
/api/v1/users
/api/v2/users
Other versioning strategies can use headers or other mechanisms depending on the API design.
Idempotency describes whether repeating the same request has the same intended effect as making it once.
GET, PUT, and DELETE are generally designed to be idempotent according to HTTP semantics, while POST is generally not idempotent.
Actual application behavior should still be verified against the API's documented contract.
Some HTTP methods are defined as safe, meaning they are intended for read-only operations and should not request a state-changing action.
GET is the most common safe method.
GET /api/productsREST API testing involves sending requests to API endpoints and validating the resulting responses.
Typical validation areas include:
Identify API Endpoint
|
v
Select HTTP Method
|
v
Prepare Headers
|
v
Prepare Authentication
|
v
Prepare Request Parameters
|
v
Prepare Request Body
|
v
Send Request
|
v
Receive Response
|
v
Validate Status Code
|
v
Validate Response Body
|
v
Validate Headers / Schema
|
v
Generate Test Result
Positive testing verifies that the API behaves correctly when valid input is provided.
Example:
POST /api/users
{
"name": "John",
"email": "[email protected]"
}
Possible expected result:
Status: 201 CreatedNegative testing verifies how the API handles invalid, incomplete, unauthorized, or unexpected input.
Example:
POST /api/users
{
"email": "invalid-email"
}
The API may return an appropriate client-error response according to its contract.
Boundary testing checks values at or around important limits.
For example, if a username has a maximum length of 50 characters, test cases can include:
API validation verifies that the response satisfies the expected contract.
Common validations include:
HTTP Status Code
+
Response Headers
+
Response Body
+
JSON Fields
+
Data Types
+
Business Rules
=
API Validation
Suppose an API returns:
{
"id": 101,
"name": "John",
"active": true
}
Tests can validate:
Schema validation verifies that a response follows the expected structural contract.
A schema can define expected properties and data types.
{
"id": 101,
"name": "John",
"active": true
}
For example, a test can verify that:
Several tools can be used to develop and execute REST API tests.
| Tool | Common Usage |
|---|---|
| Postman | Manual and automated API testing |
| cURL | Command-line HTTP requests |
| Rest Assured | Java-based API automation |
| SoapUI | API testing and service testing |
| JMeter | Performance and load testing |
| Swagger/OpenAPI tools | API documentation and exploration |
Postman is a popular tool for creating, sending, and validating API requests.
A typical Postman request can contain:
Example:
GET https://example.com/api/userscURL is a command-line utility that can send HTTP requests.
Example GET request:
curl -X GET "https://example.com/api/users"Example POST request:
curl -X POST "https://example.com/api/users" \
-H "Content-Type: application/json" \
-d '{"name":"John","email":"[email protected]"}'
REST Assured is a Java library commonly used to automate REST API testing.
It can be integrated with testing frameworks such as TestNG and JUnit.
REST Assured supports request creation, response validation, JSON processing, authentication, headers, parameters, and assertions.
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.testng.annotations.Test;
public class GetUserTest {
@Test
public void getUser() {
given()
.when()
.get("https://example.com/api/users/101")
.then()
.statusCode(200);
}
}
import static io.restassured.RestAssured.*;
import org.testng.annotations.Test;
public class CreateUserTest {
@Test
public void createUser() {
String requestBody = """
{
"name": "John",
"email": "[email protected]"
}
""";
given()
.contentType("application/json")
.body(requestBody)
.when()
.post("https://example.com/api/users")
.then()
.statusCode(201);
}
}
REST Assured can validate response status codes and JSON fields.
given()
.when()
.get("https://example.com/api/users/101")
.then()
.statusCode(200)
.body("id", equalTo(101));
This approach allows API tests to verify both HTTP behavior and response content.
REST Assured commonly uses a readable Given-When-Then structure.
given()
// Request setup
.when()
// Send request
.then()
// Validate response
| Section | Purpose |
|---|---|
| given() | Prepare request |
| when() | Execute request |
| then() | Validate response |
given()
.queryParam("category", "electronics")
.queryParam("page", 2)
.when()
.get("https://example.com/api/products")
.then()
.statusCode(200);
given()
.pathParam("id", 101)
.when()
.get("https://example.com/api/users/{id}")
.then()
.statusCode(200);
given()
.header("Accept", "application/json")
.header("Content-Type", "application/json")
.when()
.get("https://example.com/api/users")
.then()
.statusCode(200);
REST Assured supports different authentication mechanisms depending on the API.
Example of bearer-token authentication:
given()
.header("Authorization", "Bearer " + token)
.when()
.get("https://example.com/api/profile")
.then()
.statusCode(200);
Tokens should be stored and managed securely rather than hard-coded in source-controlled test code.
REST Assured can be combined with TestNG to create structured API automation suites.
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import org.testng.annotations.Test;
public class UserApiTest {
@Test
public void verifyUser() {
given()
.when()
.get("https://example.com/api/users/101")
.then()
.statusCode(200)
.body("id", equalTo(101));
}
}
TestNG Data Providers can be combined with REST Assured to execute the same API test against multiple data sets.
import static io.restassured.RestAssured.*;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class ApiDataDrivenTest {
@DataProvider(name = "users")
public Object[][] users() {
return new Object[][] {
{101},
{102},
{103}
};
}
@Test(dataProvider = "users")
public void getUserTest(int userId) {
given()
.when()
.get("https://example.com/api/users/" + userId)
.then()
.statusCode(200);
}
}
Selenium primarily automates web browsers and user-interface interactions, while REST API tools such as REST Assured are used to test backend API behavior.
Both approaches can be combined in an automation framework.
API Layer
|
| Create Test Data
v
REST API
|
v
Database / Application
|
v
Selenium UI
|
v
Verify User Interface
For example, an API can create a user before Selenium opens the application and verifies that the user appears correctly in the UI.
| Feature | API Testing | UI Testing |
|---|---|---|
| Layer | Backend/service layer | User interface |
| Browser Required | Usually no | Usually yes |
| Execution Speed | Generally faster | Generally slower |
| Validation | Requests and responses | Visible application behavior |
| Typical Tools | REST Assured, Postman | Selenium |
| Best Use | Backend and integration validation | End-user workflow validation |
Selenium and API testing complement each other rather than performing exactly the same role.
API Testing
|
+-- Backend Validation
+-- Request Validation
+-- Response Validation
+-- Business Logic
Selenium Testing
|
+-- Browser Automation
+-- UI Validation
+-- User Workflow
+-- Visual Interaction
API chaining means using data returned from one API request as input for another API request.
Create User
|
v
Receive User ID
|
v
Get User Details
|
v
Update User
|
v
Delete User
For example, the ID returned from a POST request can be used in a subsequent GET, PUT, or DELETE request.
A real application may require multiple API operations to be performed in sequence.
Login API
|
v
Receive Token
|
v
Get Products
|
v
Create Order
|
v
Get Order
|
v
Cancel Order
Testing such workflows helps verify that multiple API operations work correctly together.
API tests can also validate response-time expectations when performance requirements are defined.
Request
|
v
Start Timer
|
v
API Processing
|
v
Response
|
v
Stop Timer
|
v
Validate Response Time
Response-time checks should be based on documented requirements rather than arbitrary values.
A good API should return meaningful responses when requests fail.
Common scenarios include:
API security testing checks whether APIs properly protect sensitive resources and enforce authentication and authorization requirements.
Basic areas include:
Security testing should be performed only in authorized environments.
| Scenario | Example |
|---|---|
| Valid Request | Valid user data |
| Invalid Request | Missing required field |
| Authentication | Valid/invalid token |
| Authorization | User accessing restricted resource |
| Not Found | Invalid resource ID |
| Duplicate Data | Existing unique value |
| Boundary | Minimum/maximum values |
| Response Validation | Status and JSON fields |
| Performance | Response-time requirement |
src
|-- test
|-- java
|-- tests
| |-- UserApiTest.java
| |-- ProductApiTest.java
| |-- OrderApiTest.java
|
|-- requests
| |-- UserRequest.java
| |-- ProductRequest.java
|
|-- utilities
| |-- ConfigReader.java
| |-- JsonUtils.java
| |-- TokenManager.java
|
|-- data
| |-- UserDataProvider.java
| |-- ProductDataProvider.java
|
|-- models
|-- User.java
|-- Product.java
Test Data
|
v
TestNG / JUnit
|
v
REST Assured
|
v
Request Specification
|
v
HTTP Request
|
v
REST API
|
v
Application / Database
|
v
HTTP Response
|
v
Status Validation
|
v
Body Validation
|
v
Schema Validation
|
v
Test Report
Consider a user-management API that supports creating and retrieving users.
Step 1: Create User
POST /api/users
{
"name": "John",
"email": "[email protected]"
}
Step 2: Receive Response
{
"id": 101,
"name": "John",
"email": "[email protected]"
}
Step 3: Retrieve User
GET /api/users/101Step 4: Validate Response
Status Code = 200
id = 101
name = John
email = [email protected]
Suppose an automation framework needs to test an e-commerce application.
REST API
|
| Create Test User
v
User Created
|
| Selenium
v
Open Website
|
v
Login
|
v
Search Product
|
v
Add Product to Cart
|
v
Checkout
|
v
Verify Order
This approach can reduce unnecessary UI setup and allow API testing and UI testing to complement each other.
API automation can be executed as part of a CI/CD pipeline.
Developer Commit
|
v
Build
|
v
Unit Tests
|
v
API Tests
|
v
UI Automation
|
v
Reports
|
v
Deployment
API tests are often useful early in the pipeline because they can validate service behavior without requiring a browser.
API automation frameworks can generate test reports containing information such as:
Sensitive request or response information should be masked or excluded from reports when necessary.
| Feature | REST | SOAP |
|---|---|---|
| Type | Architectural style | Protocol |
| Common Data Format | Often JSON | Often XML |
| Transport | Commonly HTTP/HTTPS | Commonly HTTP/HTTPS and other transports |
| Complexity | Generally lightweight | Generally more formal and specification-heavy |
| Usage | Web APIs and modern services | Enterprise/service integrations |
An API is an interface that allows software applications or services to communicate with each other.
REST stands for Representational State Transfer.
A REST API is an API designed using REST architectural principles and commonly accessed through HTTP.
GET, POST, PUT, PATCH, and DELETE are commonly used HTTP methods.
GET is generally used to retrieve resources.
POST is commonly used to submit data and create resources.
PUT is generally used for replacing a resource representation, while PATCH is generally used for partial modification.
An endpoint is a URL through which a client interacts with an API resource.
JSON is a lightweight data-interchange format commonly used for REST API requests and responses.
An HTTP status code indicates the result of an HTTP request.
200 indicates that the request was successfully processed.
201 indicates that a resource was successfully created.
400 indicates that the server could not process the request because of invalid request information.
401 indicates that authentication is required or the supplied authentication is not valid.
404 indicates that the requested resource or endpoint could not be found.
API testing validates API requests, responses, business rules, authentication, status codes, and data behavior.
REST Assured is a Java library used for automating REST API tests.
Yes. REST Assured can be integrated with TestNG to create Java-based API automation suites.
API chaining is the process of using output from one API request as input for another request.
Yes. Selenium can validate UI workflows while API automation validates backend services, and both can be combined in an end-to-end automation framework.
| Concept | Description |
|---|---|
| API | Interface for software communication |
| REST | Architectural style for network-based services |
| Endpoint | URL used to access an API resource |
| GET | Retrieve data |
| POST | Create or submit data |
| PUT | Replace/update a resource |
| PATCH | Partially update a resource |
| DELETE | Delete a resource |
| JSON | Common data format for API communication |
| Header | Additional HTTP request/response information |
| Status Code | Indicates request result |
| Path Parameter | Identifies a resource in the URL path |
| Query Parameter | Filters or modifies a request |
| REST Assured | Java library for REST API automation |
| Postman | Tool for API development and testing |
Test Data
|
v
Data Provider
|
v
API Test Class
|
v
Request Specification
|
v
REST Assured
|
v
REST API
|
v
Application / Database
|
v
Response
|
+---- Status Validation
|
+---- Header Validation
|
+---- Body Validation
|
+---- Schema Validation
|
+---- Business Validation
|
v
Test Report
REST API is an important technology for communication between modern applications and backend services. REST APIs commonly use HTTP methods such as GET, POST, PUT, PATCH, and DELETE to work with application resources.
For automation testers, understanding REST API basics is valuable because many modern applications depend heavily on backend services. API testing allows testers to validate backend functionality, request and response data, authentication, business rules, error handling, and integrations without relying entirely on the browser interface.
Tools such as Postman, cURL, and REST Assured can be used to work with REST APIs. In Java-based Selenium frameworks, REST Assured can be integrated with TestNG, Data Providers, Maven, reporting systems, and CI/CD pipelines.
API automation and Selenium UI automation can also work together. APIs can be used to prepare or validate test data, while Selenium can validate the corresponding user-interface workflows.
Learn more about Selenium automation, API testing, TestNG, Page Object Model, reporting, and related automation concepts:
Final Takeaway: REST API knowledge helps automation testers understand and validate the backend services that power modern applications. By combining REST API testing with Selenium, TestNG, REST Assured, data-driven testing, and CI/CD, testers can build broader and more maintainable automation solutions.
